Skip to content

Conversation

@SangJunBak
Copy link
Contributor

@SangJunBak SangJunBak commented Dec 1, 2025

This commit introduces a new method to check if the current environmentd image reference is within the upgrade window of the last successful rollout. We default the image ref to the current version if status is not set.

Not sure if this is the best way to solve this! One nice thing is we'll see the last version everytime we upgrade which can be useful.

An edge case is if the user's materialize CR status is already set, then it won't have last_completed_rollout_environmentd_image_ref until the next successful rollout. So hypothetically, users on v26.0.0 can jump straight to v28.0.0 if they didn't upgrade between then.

We solve this by relaxing the check as much as possible, also in case of other false positives.

Screenshot 2025-12-02 at 2 01 09 PM

Motivation

Tips for reviewer

Checklist

  • This PR has adequate test coverage / QA involvement has been duly considered. (trigger-ci for additional test/nightly runs)
  • This PR has an associated up-to-date design doc, is a design doc (template), or is sufficiently small to not require a design.
  • If this PR evolves an existing $T ⇔ Proto$T mapping (possibly in a backwards-incompatible way), then it is tagged with a T-proto label.
  • If this PR will require changes to cloud orchestration or tests, there is a companion cloud PR to account for those changes that is tagged with the release-blocker label (example).
  • If this PR includes major user-facing behavior changes, I have pinged the relevant PM to schedule a changelog post.

This commit introduces a new method to check if the current environmentd image reference is within the upgrade window of the last successful rollout. We default the image ref to the current version if status is not set.
@SangJunBak SangJunBak force-pushed the jun/unskippable-release branch from edf7339 to 13a8710 Compare December 2, 2025 19:08
@SangJunBak SangJunBak marked this pull request as ready for review December 2, 2025 19:08
@SangJunBak SangJunBak requested a review from a team as a code owner December 2, 2025 19:08
Copy link
Contributor

@doy-materialize doy-materialize left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

conceptually this seems fine, but can we reuse the existing logic for checking the version compatibility? we already have an implementation of this in cloud via is_valid_upgrade_image_ref, and i think it'd be better to pull that code out to the materialize repo and use it in both places

@SangJunBak SangJunBak force-pushed the jun/unskippable-release branch from f5b4577 to b547b8f Compare December 3, 2025 17:51
@SangJunBak
Copy link
Contributor Author

@doy-materialize done in the latest commit and created a followup cloud PR https://github.com/MaterializeInc/cloud/pull/11901. More or less copied the code and tests. Two things:

  1. Noticed the cloud check is a bit more restrictive than my check. Specifically, I kind of feel like we shouldn't outright deny upgrades to dev versions in the materialize CR.
  2. How does the flow for making an update to the cloud repo after making a change to the materialize repo work? Do I need to wait for a stable release or can I just update the submodule ref?

The plan is to use this public static function in the Cloud repo. Borrows most of the same logic, but allows upgrades from/to dev versions.
@SangJunBak SangJunBak force-pushed the jun/unskippable-release branch from b547b8f to 96da51f Compare December 3, 2025 18:18
@SangJunBak SangJunBak merged commit cb0f075 into MaterializeInc:main Dec 4, 2025
129 checks passed
if next_version.major != active_version.major {
if next_version.major == 26
&& active_version.major == 0
&& active_version.minor == 164
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this should be 147

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(with a specific patch version)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ah, right, it should be both (i forgot about that since we weren't deploying those versions to cloud)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Jun is fixing it: #34371

(Version::new(0, 83, 0), Version::new(0, 83, 1)),
(Version::new(0, 83, 0), Version::new(0, 83, 2)),
(Version::new(0, 83, 2), Version::new(0, 83, 10)),
(Version::new(0, 164, 0), Version::new(26, 0, 0)),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also 147 I think

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants